OSX compatibility #4
Conversation
|
Thanks for this! One thing I spotted is that https://ui.perfetto.dev/ seems not too like the big and here's how it looks in perfetto (this example has 4 threads):
But... if I just search and replace on my text editor the big thread ids with smaller ids, it works lol:
I'll try to report it upstream, but in the meanwhile, any preference on how to work around this? I guess we could |
|
Hum, that's annoying indeed. At some point I wanted to provide a small incremental I'll make a PR and see if Koichi is open to it. |
|
Upstream PR: ruby/ruby#6189 |
|
Hum, I just though that short term this library could use a thread local variable and an atomic to generate that same serial identifier. Let me try. |
|
I discussed the upstream PR with Koichi, it may or may not be acceptable, it depends on another things he's working on, so we'll know in a bit. In the meantime I'll use a thread local to generate that same serial. |
|
Sounds reasonable. I'd still probably keep the task id for linux, since it seems like a more useful value than the not-visible-to-users serial. (?) |
`gettid()` isn't available on OSX. But we can use the Ruby's atomic and _Thread_local store to generate a serial thread id.
Up to you. I can do that if you prefer. I'd say the advantage of serial id is that it's incremental, so But I can add some code to check if |
|
I'm happy with the current version. Can always re-add the thread id later. (Happy to hear feedback from the community here) Thanks for the contribution! I'll make a release a bit later today :) |
Context: ivoanjo/gvl-tracing#4 Some hooks may want to collect data on a per thread basis. Right now the only way to identify the concerned thread is to use `rb_nativethread_self()` or similar, but even then because of the thread cache or MaNy, two distinct Ruby threads may report the same native thread id. By passing `thread->self`, hooks can use it as a key to store the metadata. NB: Most hooks are executed outside the GVL, so such data collection need to use a thread-safe data-structure, and shouldn't use the reference in other ways from inside the hook. They must also either pin that value or handle compaction.
Context: ivoanjo/gvl-tracing#4 Some hooks may want to collect data on a per thread basis. Right now the only way to identify the concerned thread is to use `rb_nativethread_self()` or similar, but even then because of the thread cache or MaNy, two distinct Ruby threads may report the same native thread id. By passing `thread->self`, hooks can use it as a key to store the metadata. NB: Most hooks are executed outside the GVL, so such data collection need to use a thread-safe data-structure, and shouldn't use the reference in other ways from inside the hook. They must also either pin that value or handle compaction.
gettid()isn't available on OSX. But we can use the Ruby'sthread_native.hto get an identifier.